RIDS by Document and Section 


RID-92L-01 CORE SS 3.4.2 Action Verification Insufficient preCheckAction information. 

RID-92L-02 CORE SS 4.2.4.2 invokeAction: Structures Add field for time trigger. 
RID-92L-03 CORE SS 4.2.4.3 Action update Inconsistent with Common Model update. 
RID-92L-06 CORE SS 4.2.4.4 invokeAction: Extra Information Usage 
RID-92L-07 CORE SS 4.2. 5.4 preCheckAction: Extra Information 

RID-92L-04 CORE SS 5.1.1 Action definitions are not provided by MO protocol. 

RID-92L-05 CORE SS 5.1.3 Inconsistent action status handling. 

RID-92S-1 1 CORE SS 5.3.1 1 Provide more parameter states. 

RID-92L- 1 1 COMM SS 3.3 Need more concrete example of DS nodes. 

RID-92L-12 COMM SS 3.3.1 Table reference error 

RID-92L-13 COMM SS 3.3, Table: DS Addr Fids: DataURI usage is not clear 

RID-92S-09 COMM SS 3.3, Table: DS Addr Fids: Table column heading edit. 

RID-92S-10 COMM SS 3.3, Table: DS Addr Fids: Clarify the Data URI value reference. 

RID-92S-02 COMM SS 4.2.3 Define protection for sensitive data that is brokered. 
RID-92S-14 COMM SS 4.2.9 Implementation of definition changes 
RID-92S-04 COMM SS 4.2.1 1.4 Define more error information for subscription lists. 

RID-92L- 14 COMM SS 4.3 Call for rationale 
RID-92L-15 COMM SS 4.3.3 Clarify intent. 

RID-92L-16 COMM SS 4.3.4 Structure factoring 
RID-92L-19 COMM SS 4.3.5 Make DS recurse instead of clients. 

RID-92L-17 COMM SS 4.3.6 Removing empty nodes. 

RID-92L- 1 8 COMM SS 4.3.7. 1 Add an addLink-helper feature to DS 

RID-92L-20 COMM SS 4.3.9 Missing DomainOccurrence and publishService 
RID-92L-27 COMM SS 4.3. 9.4 Extra Information Usage 
RID-92L-28 COMM SS 4.3.1 1.4 Extra Information Usage 

RID-92L-21 COMM SS 5.4.1 Service type number not included in tables. 

RID-92L-22 COMM SS 5.4.7 Incorrect link 
RID-92L-23 COMM SS 5.4.8 Inconsistent ontology 
RID-92L-24 COMM SS 5.4.13 Inconsistent ontology 
RID-92L-25 COMM SS 5.4.16 Inconsistent references 
RID-92L-26 COMM SS 5.4.18 Inconsistent references 

RID-92S-01 MAL SS 4.9.2 "Fixed" ack msg is confusing 

RID-92S-03 MAL SS 4.13.7 Allow local PUB SUB pattern variants. 

RID-92R-01 MAL SS 6.1.7 Confusion over Service definition components. 

RID-92S-05 MAL SS 6.1.7 Service Operation Identifier type is unclear. 

RID-92S-06 MAL SS 6.1.7 Ambiguous URIfrom reference. 

RID-92S-07 MAL SS 6.1.7 How will Transport/Encoding versions be registered? 
RID-92S-08 MAL SS 6.1.7 Suggestion for readability 
RID-92R-02 MAL SS 6.1.12 sourceURI is ephemeral. 



RIDS by Number 


RID-92L-01 CORE SS 3.4.2 Action Verification Insufficient preCheckAction information. 
RID-92L-02 CORE SS 4.2.4.2 invokeAction: Structures Add field for time trigger. 
RID-92L-03 CORE SS 4.2.4.3 Action update Inconsistent with Common Model update. 
RID-92L-04 CORE SS 5. 1 . 1 Action definitions are not provided by MO protocol. 

RID-92L-05 CORE SS 5.1.3 Inconsistent action status handling. 

RID-92L-06 CORE SS 4.2.4.4 invokeAction: Extra Information Usage 
RID-92L-07 CORE SS 4.2. 5.4 preCheckAction: Extra Information 

RID-92L- 1 1 COMM SS 3.3 Need more concrete example of DS nodes. 

RID-92L-12 COMM SS 3.3.1 Table reference error 

RID-92L-13 COMM SS 3.3, Table: DS Addr Fids: DataURI usage is not clear 

RID-92L- 14 COMM SS 4.3 Call for rationale 

RID-92L-15 COMM SS 4.3.3 Clarify intent. 

RID-92L-16 COMM SS 4.3.4 Structure factoring 
RID-92L-17 COMM SS 4.3.6 Removing empty nodes. 

RID-92L-18 COMM SS 4.3.7. 1 Add an addLink- helper feature to DS 
RID-92L-19 COMM SS 4.3.5 Make DS recurse instead of clients. 

RID-92L-20 COMM SS 4.3.9 Missing DomainOccurrence and publishService 

RID-92L-21 COMM SS 5.4.1 Service type number not included in tables. 

RID-92L-22 COMM SS 5.4.7 Incorrect link 

RID-92L-23 COMM SS 5.4.8 Inconsistent ontology 

RID-92L-24 COMM SS 5.4.13 Inconsistent ontology 

RID-92L-25 COMM SS 5.4.16 Inconsistent references 

RID-92L-26 COMM SS 5.4.18 Inconsistent references 

RID-92L-27 COMM SS 4.3. 9.4 Extra Information Usage 

RID-92L-28 COMM SS 4.3. 1 1 .4 Extra Information Usage 

RID-92R-01 MAL SS 6.1.7 Confusion over Service definition components. 

RID-92R-02 MAL SS 6.1.12 sourceURI is ephemeral. 

RID-92S-01 MAL SS 4.9.2 "Fixed" ack msg is confusing 

RID-92S-02 COMM SS 4.2.3 Define protection for sensitive data that is brokered. 

RID-92S-03 MAL SS 4.13.7 Allow local PUB SUB pattern variants. 

RID-92S-04 COMM SS 4.2.1 1.4 Define more error information for subscription lists. 
RID-92S-05 MAL SS 6.1.7 Service Operation Identifier type is unclear. 

RID-92S-06 MAL SS 6.1.7 Ambiguous URIffom reference. 

RID-92S-07 MAL SS 6.1.7 How will Transport/Encoding versions be registered? 

RID-92S-08 MAL SS 6.1.7 Suggestion for readability 

RID-92S-09 COMM SS 3.3, Table: DS Addr Fids: Table column heading edit. 

RID-92S-10 COMM SS 3.3, Table: DS Addr Fids: Clarify the Data URI value reference. 
RID-92S- 1 1 CORE SS 5.3.11 Provide more parameter states. 

RID-92S-14 COMM SS 4.2.9 Implementation of definition changes 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-01 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 522.0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Core Services Draft Recommended Standard" 
DATE ISSUED: April 2008 


PAGE/PARA NUMBER: Core Services, Section 3.4.2 Action Verification 

RID SHORT TITLE: Insufficient preCheckAction information. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
Please clarify. 

The paragraph provides a pre-check scenario where the client could perform 
action argument checks. The preCheckAction returns an error if the arguments 
are invalid. The invokeAction will return the identical error for invalid 
arguments. What value does the preCheckAction provide in this case? Is it to 
determine the validity of the arguments to issue an invoke at a later time? If 
preCheckAction returns false, there is no indication of why. The client may 
require knowledge of whether the link to the vehicle is down or the vehicle is 
in an invalid state to accept the command. 

The last paragraph indicates the subscription process allows a client to filter 
on the status information returned. The Action service only has the 
invokeAction and preCheckAction available. Is the subscription process 
referring to the VerificationStageList included in the invokeAction arguments? 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-02 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 522.0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Core Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: CORE, Section 4.2.4.2 invokeAction Structures 
RID SHORT TITLE: Add field for time trigger. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

The input structure needs to allow for a time trigger. The execution time is 
the time the action shall be executed on board the vehicle. This field is 
optional. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-03 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

DOCUMENT NUMBER: CCSDS 522.0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Core Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: CORE, Section 4.2.4.3 

RID SHORT TITLE: Action update Inconsistent with Common Model update. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
invoke Action Common Model Updates: 

The second paragraph implies there will be multiple updates for for each 
VerificationStage and the final update when the invoke is complete. The 
final paragraph of section 4.2. 3.2 indicates each stage is reported using a 
VerificationStateStatus except for the PROGRESS stage which uses 
VerificationProgressStatus. 

The VerificationProgressStatus does not contain the state attribute( IDLE, 
COMPLETED etc). The PROGRESS interaction pattern in the MAL provides for 
multiple PROGRESS updates but only one response. Accordingly, there can only 
be one VerificationStateStatus which is included in the response. This 
interpretation conflicts with the Common Model Updates paragraph which implies 
multiple VerificationStateStatus updates per progress updates. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-04 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 522.0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Core Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: CORE, Section 5.1.1 

RID SHORT TITLE: Action definitions are not provided by MO protocol. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
Action Definition: 

The action arguments are in the structure Common: :DefinitionKeyList. This structure 
is a list of the entityld and and definitionld. What are these two attributes 
(possibly argument name and description)? At a minimum, the parameter type 
(String, Integer, Floating Point, Time), engineering units, lower limit and 
upper limit are needed to allow a client to provide the correct value for the 
argument. A discovery mechanism for the Action Definitions needs to be 
provided; otherwise, the action definitions will need to be distributed to 
clients of the Action Service. Configuration may be the intended location for 
this type of information; however, that limits the interoperability an 
implementation may have to centers that can agree on a configuration format. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-05 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 522.0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Core Services Draft Recommended Standard" 
DATE ISSUED: April 2008 


PAGE/PARA NUMBER: CORE, Section 5.1.3 Action Status 
RID SHORT TITLE: Inconsistent action status handling. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

The comment for the VerificationStatusList indicates an entry is made for each 
stage requested in the ActionOccurrence list. VerificationStatus consists of 
only the Delay and VerificationStage. The VerificationStateStatus contains 
the VerificationState but this is only present on the final response. With 
the VerificationState, for each stage, a list containing each entry makes 
sense. The VerificationProgress Status only contains the current step of the 
total steps. The status is not an attribute. Including all the values in the 
list, as opposed to just the current progress update, seems of little value. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 

Below are the xml excerpts for one interpretation of the messages required for 
this pattern. The Common Model attributes are not completed as that part has 
not been prototyped. The message header is removed for brevity and the 
version implementation is not from the latest MAL. Please advise to the 
correctness of the messages. 


InvokeAction Input 

<action:InvokeActionRequest> 

<action:actionOccurrence> 



<common:key> 

<common:entityId>CMD 1001 </common:entityId> 

<common:definitionId xsi:nil="true" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> 
<common: occurrenceld xsi : nil="true " 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> 

</common:key> 

<common:timestamp>2009 -0 1 -09T 1 1 :30:3 8. 1 96-06:00</common:timestamp> 
<action:verificationStageList> 

RELEASE RECEIPT AEPTANCE EXECUTION COMPLETION 
</action:verificationStageList> 

</action:actionOccurrence> 

</action:InvokeActionRequest> 


InvokeAction Acknowledgment 

<action:InvokeActionAck> 

<action:occurrenceKey> 

<common:entityId>CMD 1001 </common:entityId> 
<common:definitionIdx/common:definitionId> 
<common : occurrenceldx/common : occurrenceId> 
</action:occurrenceKey> 
</action:InvokeActionAck> 


InvokeAction Progress Update[l] 

<action:InvokeActionProgress> 

<action:actionStatus xsi:type="action:ActionStatusType"> 

<common:key> 

<common:entityId>CMD 1001 </common:entityId> 

<common : definitionldx/common: definitionId> 

<common: occurrenceldx/common : occurrenceId> 

<common: statusldx/common : statusld> 

</common:key> 

<common:timestamp>2009-01 -09T1 1 :30:38.340550</common:timestamp> 
<action:verificationStageStates> 

<action : verificationProgress Status 

xsi:type="action:VerificationProgressStatus"> 

<action : duration> 1 44</action: duration> 
<action:verificationStage>RELEASE</action:verificationStage> 
<action:stepNumber>0</action:stepNumber> 
<action:ofSteps>4</action:ofSteps> 

</action:verificationProgressStatus> 

</action:verificationStageStates> 

</action:actionStatus> 

</action:InvokeActionProgress> 


InvokeAction Progress Update[5] 

<action:InvokeActionProgress> 

<action:actionStatus xsi:type="action:ActionStatusType"> 



<common:key> 

<common:entityId>CMD 1001 </common:entityId> 
<common:definitionIdx/common:defmitionId> 

<common : occurrenceldx/common : occurrence!d> 

<common: statusldx/common: statusld> 

</common:key> 

<common:timestamp>2009-01-09Tl 1 :30:38.440215</common:timestamp> 
<action:verificationStageStates> 

<action:verificationProgressStatus 

xsi:type="action:VerificationProgressStatus"> 

<action:duration>244</action:duration> 

<action:verificationStage>COMPLETION</action:verificationStage> 
<action : stepN umber>4</action: stepNumber> 

<action : ofSteps>4</action : ofSteps> 
</action:verificationProgressStatusx/action:verificationStageStates> 
</action:actionStatusx/action:InvokeActionProgress> 


InvokeAction Response 

<action:InvokeActionResponse> 

<action:actionStatus xsi:type="action:ActionStatusType"> 

<common:key> 

<common:entityIdx/common:entityId> 

<common:definitionIdx/common:definitionId> 

<common:occurrenceIdx/common:occurrenceId> 

<common: statusldx/common: statusld> 

</common:key> 

<common:timestamp>2009-01-09Tl 1 :30:38.457778</common:timestamp> 
<action:verificationStageStates> 

<action:verificationStateStatus xsi:type="action:VerificationStateStatus"> 
<action : duration> 1 44</action : duration> 
<action:verificationStage>RELEASE</action:verificationStage> 

<action: state>PASSED</action: state> 

</action:verificationStateStatus> 

<action:verificationStateStatus xsi:type="action:VerificationStateStatus"> 
<action : duration> 1 5 5</action : duration> 
<action:verificationStage>RECEIPT</action:verificationStage> 

<action : state>P AS SED</action: state> 

</action:verificationStateStatus> 

<action:verificationStateStatus xsi:type="action:VerificationStateStatus"> 
<action:duration>2 1 0</action:duration> 

<action:verificationStage>ACCEPTANCE</action:verificationStage> 
<action : state>P AS SED</action: state> 

</action:verificationStateStatus> 

<action:verificationStateStatus xsi:type="action:VerificationStateStatus"> 
<action:duration>233</action:duration> 

<action:verificationStage>EXECUTION</action:verificationStage> 
<action: state>P ASSED</action: state> 

</action:verificationStateStatus> 

<action:verificationStateStatus xsi:type="action:VerificationStateStatus"> 
<action:duration>244</action:duration> 

<action:verificationStage>COMPLETION</action:verificationStage> 
<action: state>P ASSED</action: state> 



</action:verificationStateStatus> 

</action:verificationStageStates> 

</action:actionStatus> 

</action:InvokeActionResponse> 

DISPOSITION: 




* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-06 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Core Services Draft Recommended Standard" 
DATE ISSUED: May 2008 

PAGE/PARA NUMBER: Section 4.2.4.4 

RID SHORT TITLE: invoke Action Extra Information Usage 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
InvokeAction errors 

The extrainformation field should be allowed to contain at least the first 
invalid argument in the list for an INVALID error. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended X Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-30 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Core Services Draft Recommended Standard" 
DATE ISSUED: May 2008 

PAGE/PARA NUMBER: Section 4.2.5.4 

RID SHORT TITLE: preCheckAction Extra Information 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
preCheckAction errors 

The extrainformation field should be allowed to contain at least the first 
invalid argument in the list for an INVALID error. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended X Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L- 1 1 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 3.3 

RID SHORT TITLE: Need more concrete example of DS nodes. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
Directory Service: 

Figure 3-88 provides assistance in understanding the Directory Service nodes; 
however, a more concrete example with values for the Domain, Network Zone, and 
Sessions would be helpful. Also, the example could be expanded in increments 
to demonstrate the sub domain nodes, external nodes and how services are 
represented in the NodeStatus. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended Editorial X 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L- 1 2 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 3.3.1 

RID SHORT TITLE: Table reference error 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
Service Provider Properties: 

First paragraph refers an typo where it refers to Table 3-2 instead of Table 3-22. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended Editorial X 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L- 1 3 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Table 3-11 

RID SHORT TITLE: DataURI usage is not clear 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
Directory Service Address Fields: 

An explanation of why the DataURI is necessary for Pub/Sub interaction 
patterns is necessary would be helpfiil. Is it simply a separation of concerns 
or performance issue to provide different addresses for the non Pub/Sub 
interactions? Or, is it acceptable to use the dataURI for identifying the 
transport layer topics for subscriptions? 


DISPOSITION: 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L- 14 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 4.3 

RID SHORT TITLE: Call for rationale 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
Directory Service: 

The directory services is significantly more complex in this document than the 
previous version that went through the review process (September 2007). It is 
not clear what value the additional complexity provides. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended Editorial X 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L- 1 5 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 4.3.3 

RID SHORT TITLE: Clarify intent. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
Common Model Usage: 

The second paragraph states that each node in the directory service is 
identified by the OccurrenceKey: 

entityld = domain Identifier, 
definitionld = Network, 
occurrenceld = Session Name. 

The services are represented with ServiceNodeStatus that contains the 
ServiceDetails and Providerlnformation. It is not explicitly stated the 
entityld, defintionld and occurrenceld of the Status serve as the primary 
key. It appears that this must be true in order to tie the domain and 
services together. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L- 1 6 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 4.3.4 

RID SHORT TITLE: Structure factoring 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
Operation createNode: 

This operation takes a list of DomainOccurrence as the argument. The 
OccurrenceKey services as the key. The publish operation takes a list of 
NodeStatus as the argument. The StatusKey serves as the key for this 
structure. Consider using the same structure to represent the keys. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended X Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L- 1 7 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 4.3.6 

RID SHORT TITLE: Removing empty nodes. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
removeNode: 

Can a domain node be removed that has related services in the 
ServiceStatusNode? It is not clear whether the services can exist without 
the nodes. If so, what is the purpose of the nodes? 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended Editorial X 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L- 1 8 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 4.3.7. 1 

RID SHORT TITLE: Add an addLink-helper feature to DS 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
Operation addLink: 

The first paragraph indicates the external nodes are added but not created. 

It not clear how a node can be added but not created. Section 4.3. 8. 3 in the 
Common Model Updates indicate the nodes are created by the addLink operation. 

Consider making it the responsibility of the Directory Service to issue the 
addLink calls whenever a publish event is received. This would require a 
DirectoryService that contains Directory Service providers only. It would hide 
the distributed nature of the Directory Services from the service provider 
clients. 

Is it possible for an external node to point to another external node? Or 
alternately, do all external nodes point the Directory Service where the 
internal node is hosted? 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended X Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L- 1 9 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 4.3.5 

RID SHORT TITLE: Make DS recurse instead of clients. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
resolveNodeURI: 

The description of this method implies the clients will be responsible for 
determining the URI of a service provider via iterative name resolution. The 
caller would be responsible for determining that the node was external and 
retrieve the address of the directory service that contains the action entry. 

Consider a recursive name resolution strategy where the Directory Service is 
responsible for traversing the external nodes and returning the client the 
ServiceDetails structure. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended X Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-20 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 4.3.9 

RID SHORT TITLE: Missing DomainOccurrence and publishService 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
publishService: 

Is a DomainOccurrence required for the domain, network and session identifier? 
If the DomainOccurrence is not present, should this operation attempt to 
create it? 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-21 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 5.4. 1 

RID SHORT TITLE: Service type number not included in tables. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
DomainOccurrence : 

The services attribute indicates [that] it is a list of identifiers combining 
the service area and service type numbers. The service type number is not [a] 
field on the service operation matrices, (e.g. Table 4-66) 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended Editorial X 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-22 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 5.4.7 

RID SHORT TITLE: Incorrect link 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
NodeStatus: 

The services Field is of type ServiceDetailsInfoList which does not exist. 

The hyperlink goes to ServiceDetailsList 


REQUESTED CHANGE: 


CATEGORYOF 


Technical Fact Recommended Editorial X 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-23 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 5.4.8 

RID SHORT TITLE: Inconsistent ontology 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
NodeStatusList: 

This structure does not follow the naming standard for List structures. It is 
a list of ServiceStatusNodeStatus. The hyperlink is invalid. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended Editorial X 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-24 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 5.4. 1 3 

RID SHORT TITLE: Inconsistent ontology 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
ProviderlnformationList: 

This structure does not follow the naming standard for List structures. It is 
a list of ServicelnfoProviderlnformation. The hyperlink is invalid. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended Editorial X 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-25 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 5.4. 1 6 

RID SHORT TITLE: Inconsistent references 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
DomainLink: 

It is not clear why the DomainLink uses the DomainOccurrence as the key but 
the ServiceDetails is identified by the StatusKey. The paragraph states the 
ServicelnfoProviderlnformation structure is part of the DomainLink. The table 
refers to the Providerlnformation structure. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended Editorial X 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-26 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 5.4. 1 8 

RID SHORT TITLE: Inconsistent references 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
ServiceFilter: 

This structure uses the OccurrenceKey to aid in identification of the 
ServiceDetails but the ServiceDetails uses the StatusKey. Consider avoiding 
the use of multiple key structures. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended Editorial X 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-27 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 4.3.9.4 

RID SHORT TITLE: Extra Information Usage 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
Publish Service errors 

The extrainformation field should be allowed to contain at least the first 
invalid value when returning an Invalid error. Referenced table 5-22 is 
not available in the document. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended X Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92L-28 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Steven A. Lucord 
CODE: JSC:DD12 

E-MAIL ADDRESS: steven.a.lucord@nasa.gov 
TELEPHONE: 281-483-9711 


DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 
DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 4.3 . 1 1 .4 

RID SHORT TITLE: Extra Information Usage 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 
Withdraw Service errors 

The extrainformation field should be allowed to contain at least the first 
unknonw service that caused the UNKNOWN error 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended X Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92R-0 1 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Walt Reynolds 
CODE: JSC:DD12 

E-MAIL ADDRESS: walter.f.reynolds@nasa.gov 
TELEPHONE: 281-483-6723 


CUMENT NUMBER: CCSDS 521 .0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Message Abstract Layer Draft 

Recommended Standard" 

DATE ISSUED: April 2008 

DOCUMENT NUMBER: CCSDS 521.1-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 

DATE ISSUED: April 2008 

DOCUMENT NUMBER: CCSDS 522.0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Core Services Draft Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: MAL Section 6.1.7 

COMMON Sections 5.3.22, 5.4.1, 5.4.9, 5.8.4, 6 
CORE Section 6 

RID SHORT TITLE: Confusion over Service definition components. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

Parameters in question: 

Service Area Identifier (area) 

Service Identifier (service ID) 

Serivce Operation Identifier (operation) 

Service Version (version) 

The MAL (ss 6.1.7) shows the actual type of these parameters as MAL: identifier, 
and MAL::Octet for Version. For the MAL: identifier based parameters, this 
allows the use of National Language definitions with UTF-16 encoding (note that 
the Asian large glyph code point tables repeat various values from the 
LATIN- 1/ASCII map). It appears, however, that enumerated integer values are 
intended for area, service ID, and operation. This would remedy ambiguous 
encoding due to linguistics and graphics. 


But this is not clearly put forth in all cases: 

ServicesFilter (COM ss 5.4.18) and ServiceDetails (COM ss 5.4.9) shows the area 



and service ID as MAL: identifiers, but note that the version is a MAL::Short. 

Is is therefore possible to register a service with version 256 even though the 
MAL message header cannot support this. 

But SelectionCriteria (COM ss 5.8.4) and UpdateSource (COM ss 5.3.22) shows area 
and service ID as MAL:: Shorts; the list of services found at a node by Directory 
Services as seen in DomainOccurrence (COM ss 5.4.1) defines a service as the 
concatenation of numeric values, separated by colons, all expressed as a single 
URI-like string — eg. "0::3", for <area>:<service ID>:<version>. (Note that I 
am assuming the last element is version). The Archive data structures in 
general (COM ss 5.8.12, 5.8.14, 5.8.16), indicated that the area and service ID 
data elements are MAL:: Shorts as well. 

operation can be encoded as either an integer or a string since both are 
provided in the Service and Operation Summary sections in Core and Common (ss 
6). But which do we actually use? 


RECOMMENDATION: 

Only use integral types for area, service ID, operation. And only use 

MAL:: Shorts in all cases. This prevents any opportunity for ambiguous encodings 

due to spelling, linguistics and graphics. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 






* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92R-02 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: Walt Reynolds 
CODE: JSC:DD12 

E-MAIL ADDRESS: walter.f.reynolds@nasa.gov 
TELEPHONE: 281-483-6723 


CUMENT NUMBER: CCSDS 521 .0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Message Abstract Layer Draft 

Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: MAL Section 6. 1 . 12 

RID SHORT TITLE: sourceURI is ephemeral. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

Should we use a service definition (area/servicelD/version) instead of the URI? 
The URI may be ephemeral and, therefore, its use could create a stale network 
reference. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended X Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 




* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92S- 1 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: John E. Stevens 
CODE: JSC:DD12 

E-MAIL ADDRESS: john.stevens@nasa.gov 
TELEPHONE: 281-483-6476 


DOCUMENT NUMBER: CCSDS 52 1 .0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Message Abstract Layer Draft Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: Section 4.5.2 / pg 4-9 

RID SHORT TITLE: "Fixed" ack msg is confusing 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

The statement that the "acknowledge message is fixed" needs to be explained. 
The term fixed is confusing, especially considering the success and error 
acknowledge messages represent two different forms (the error case contains 
the StandardError body type while the success case form is unclear). 

Does the term "fixed" refer to the entire submit message (header and body) 
being bounced back as the acknowledge message with response related header 
changes for the success case? Or does "fixed" refer to a general acknowledge 
message format (e.g. just the message header reply without the body)? I 
assume "fixed" doesn't refer to the content of the acknowledge message 
matching that of the submit message. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92S-02 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: John E. Stevens 
CODE: JSC:DD12 

E-MAIL ADDRESS: john.stevens@nasa.gov 
TELEPHONE: 281-483-6476 


DOCUMENT NUMBER: CCSDS 52 1 .0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Message Abstract Layer Draft Recommended Standard" 

DATE ISSUED: April 2008 

DOCUMENT NUMBER: CCSDS 52 1 . 1 -R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 

DATE ISSUED: April 2008 

DOCUMENT NUMBER: CCSDS 522.0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Core Services Draft Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: MAL pg 4-30 Figure 4- 14; 

COMMON Sections 4.2.3, 4.2.11; 

CORE Section 5.2.10 


RID SHORT TITLE: Define protection for sensitive data that is brokered. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

It's unclear how the SM&C Standards address the protection of sensitive 
[data in] entity instances. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 

[In the] Consumer- Broker-Provider implementation, the Provider is unaware of 
Consumers' registration and deregistrations, therefore the Broker not only 
manages the Consumers's notifications, it's also responsible for authorising 
access to requested items ([...] sensitive information). 

The ParameterDefinition structure doesn't define such restrictions (a 
Consumer's role can be obtained based on the Consumer's authentication 
credentials from the Login Services). By implementation, sensitive data can 



be filtered out at the Provider level if the transmission between it and a 
Broker requires it, and network security measures can be applied for Brokers 
requiring access to sensitive data. In the latter case, the Brokers would use 
a Consumer's roles and a list of known_ sensitive (restricted) parameters to 
authorize access. 

Who owns the ParameterDefinition (the Provider or Provider's Broker)? 


DISPOSITION: 


* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92S-03 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: John E. Stevens 
CODE: JSC:DD12 

E-MAIL ADDRESS: john.stevens@nasa.gov 
TELEPHONE: 281-483-6476 


DOCUMENT NUMBER: CCSDS 52 1 .0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Message Abstract Layer Draft Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: MAL p. 4-33 section 

RID SHORT TITLE: Allow local PUB SUB pattern variants. 

DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

Allow site-based configuration of different messages for the PUBSUB pattern. 

CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended X Editorial 


SUPPORTING ANALYSIS: 

In the PUBSUB pattern, the Provider will be unaware of any publish failures, 
since the publish message is a SEND vs. a SUBMIT pattern. This can be a 
problem for multiple contributing Providers each contributing updates to a 
single data stream (i.e. a single data component using a shared Broker). If 
one Provider fails to publish, it may not be able to react immediately to the 
error. Publishing errors may be due to an authentication error, an 
authorization error, a configuration error such as an incompatible parameter 
definition, or a rejection based on a functional requirement. 

The argument against making the publish message a SUMBIT pattern is the amount 
of traffic it will produce across the space link. The other consideration is 
the potential need for cooperating Agencies or Centres to inject derived 
computations into the appropriate data stream(s). 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92S-04 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: John E. Stevens 
CODE: JSC:DD12 

E-MAIL ADDRESS: john.stevens@nasa.gov 
TELEPHONE: 281-483-6476 


DOCUMENT NUMBER: CCSDS 52 1 .0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Message Abstract Layer Draft Recommended Standard" 

DATE ISSUED: April 2008 

DOCUMENT NUMBER: CCSDS 52 1 . 1 -R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: MAL pg 4-46 Section 4. 10.3, pg 6-5 Section 6. 1 .8; 

COMMON pg 4-20 Sect. 4.2.1 1.4; CORE Sect. 4.3 

RID SHORT TITLE: Define more error information for subscription lists. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

There's no way for a Consumer to know which parameter was in error unless 
identified in the extrainformation field. MAL Section 4.10.3 states "[the] 
error structure allows a service specification to add extra information to the 
error returned but this must be specified by the service operation definition. 

The Common Model Service's monitorStatus operation definition (section 4.2.1 1.4) 
and the Parameter Service's operations definitions (section 4.3) each do not 
specify an error structure. Users will want to know which parameters are in 
error. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92S-05 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: John E. Stevens 
CODE: JSC:DD12 

E-MAIL ADDRESS: john.stevens@nasa.gov 
TELEPHONE: 281-483-6476 


DOCUMENT NUMBER: CCSDS 52 1 .0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Message Abstract Layer Draft Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: MAL pg 6-4 Section 6. 1 .7 

RID SHORT TITLE: Service Operation Identifier type is unclear. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

The MessageHeader operation field's comment notes this field to be the 
"Service Operation Identifier". It's unclear if this is the "Operation Name" 
or the "Operation Number". It's implied to be the Operation Name; whatever 
the case may be[, this] needs to be explicitly stated (even if it's either). 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92S-06 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: John E. Stevens 
CODE: JSC:DD12 

E-MAIL ADDRESS: john.stevens@nasa.gov 
TELEPHONE: 281-483-6476 


DOCUMENT NUMBER: CCSDS 52 1 .0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Message Abstract Layer Draft Recommended Standard" 

DATE ISSUED: April 2008 

DOCUMENT NUMBER: CCSDS 52 1 . 1 -R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: MAL pg 3-2&3 Section 3.2.3, pg 6-4 Section 6.1.7; 

COMMON pg 3-5 Section 3.2 

RID SHORT TITLE: Ambiguous URIfrom reference. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

[...] Clarify the appropriate use of the URI fields [— ] mention of how the 
fields are utilised relative to Domains. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 

When the specified Domain is implicit (generic multi-domain) resulting in 
multiple PUB -SUB Providers, it isn't obviously clear which URI applies to the 
notify MessageHeader's URIfrom field. Based on the MAL Domain description 
(MAL section 3.2) and the Common Services Directory Service concept, it 
appears the Broker address can be used when a "shared data provider" name is 
defined; in this case the notify message can contain items from multiple 
Providers. But if the Domain spreads across many independent direct Providers 
and/or Brokers (shared or non-shared), the absolute address of each 
Provider/Broker will have to be used separately. In this case the Consumer 
will have to organize its data items according to each Provider's specific 
domain, then issue separate operations to the appropriate Provider URI 
(resulting in separate Provider/Broker domain specific replies). It would be 
useful to discuss these scenarios somewhere and have the aforementioned [...] 



sections reference it. 


DISPOSITION: 




* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92S-07 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: John E. Stevens 
CODE: JSC:DD12 

E-MAIL ADDRESS: john.stevens@nasa.gov 
TELEPHONE: 281-483-6476 


DOCUMENT NUMBER: CCSDS 52 1 .0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Message Abstract Layer Draft Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: MAL p. 6-4 section 6. 1 .7 

(and in general for structure definitions) 

RID SHORT TITLE: How will Transport/Encoding versions be [registered]? 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

It is unclear how applications can knowingly select a Service with a compliant 
Transport/Encoding Standard version. (How will an application know which 
version of the Transport/Encoding to use, unless the advertised Service 
version somehow ties the SM&C Service Standard version, the SM&C MAL and 
Common Standards version, and the Transport/Encoding Standard version?). The 
comment on the MessageHeader version field should explain what exactly a service 
version is. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92S-08 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: John E. Stevens 
CODE: JSC:DD12 

E-MAIL ADDRESS: john.stevens@nasa.gov 
TELEPHONE: 281-483-6476 


DOCUMENT NUMBER: CCSDS 52 1 .0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Message Abstract Layer Draft Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: MAL pg 6-4 Section 6. 1 .7 

(Generally applies to all structures definitions) 

RID SHORT TITLE: Suggestion for readability 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

As a reference, it is easier on an implementor to have enough structure details 
available with the structure's definition. As is, the implementor has to search 
through the documents for the details. It would be very helpful to have 
detailed structure field descriptions vs. generalized comments alone. Where 
applicable, descriptions should discuss how the field supports interoperability 
(cases in point, the MessageHeader's URIto/URIffom fields, and Service version 
fields discussed in previous RID's). Some fields at least deserve a section 
reference for further details. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended Editorial X 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92S-09 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: John E. Stevens 
CODE: JSC:DD12 

E-MAIL ADDRESS: john.stevens@nasa.gov 
TELEPHONE: 281-483-6476 


DOCUMENT NUMBER: CCSDS 52 1 . 1 -R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: COMMON pg 3-5 Table 3-1 

RID SHORT TITLE: Table column heading edit. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

Under the Comment column of the "Data URI" row, the reference "shared data 
provider" should immediately be followed with "(broker)" as was done on the next 
row. 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact Recommended Editorial X 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92S- 10 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: John E. Stevens 
CODE: JSC:DD12 

E-MAIL ADDRESS: john.stevens@nasa.gov 
TELEPHONE: 281-483-6476 


DOCUMENT NUMBER: CCSDS 52 1 . 1 -R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: COMMON p. 3-5 Table 3-1 

RID SHORT TITLE: Clarify the Data URI value reference. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

Under the Comment column of the "Shared data provider name" row, it states 
"... then the Data URI value of named provider shall be used". If the "if 
clause" holds, then the Data URI value used will be empty (NULL). Is 
this correct? This comment needs clarification. I assume the following 
sentence is what was intended: "The field is used to identify a shared data 
provider (broker) when this field contains a value and the Data URI field is 
empty. When the Data URI contains a value it takes precedence over the shared 
data provider value." 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



* Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92S- 1 1 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: John E. Stevens 
CODE: JSC:DD12 

E-MAIL ADDRESS: john.stevens@nasa.gov 
TELEPHONE: 281-483-6476 


DOCUMENT NUMBER: CCSDS 522.0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Core Services Draft Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: CORE pg 5-16 Section 5.3.1 1 

RID SHORT TITLE: Provide more parameter states. 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

It's unclear how to map the generic UNEXPECTED/LOW/HIGH state to the specific 
check states based on the current set of structures (e.g. HIGH: Out-of-Limits 
High or Off-Scale High; LOW: Out-of-Limits Low or Out-of-Scale Low; 
UNEXPECTED: to spacecraft/ground specific check states). 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 


DISPOSITION: 



:w *Informal* REVIEW ITEM DISPOSITION (RID) INITIATION FORM 


AREA RID NUMBER: 92S- 14 

SUBMITTING ORGANIZATION (Area, WG): NASA/JSC/OTF 


REVIEWER'S NAME: John E. Stevens 
CODE: JSC:DD12 

E-MAIL ADDRESS: john.stevens@nasa.gov 
TELEPHONE: 281-483-6476 


DOCUMENT NUMBER: CCSDS 52 1 .0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Message Abstract Layer Draft Recommended Standard" 

DATE ISSUED: April 2008 

DOCUMENT NUMBER: CCSDS 52 1 . 1 -R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Common Services Draft Recommended Standard" 

DATE ISSUED: April 2008 

DOCUMENT NUMBER: CCSDS 522.0-R-2 RED BOOK 

DOCUMENT NAME: "Mission Operations - Core Services Draft Recommended Standard" 

DATE ISSUED: April 2008 

PAGE/PARA NUMBER: COMMON, CORE, MAL 

RID SHORT TITLE: Implementation of definition changes 


DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) 

How do Configuration Service changes impact the respective Parameter and Check 
Services definitions? (I assume Consumers/Brokers will need to continuously 
monitor/react to potential configuration changes.) 

What happens if the parameter definitions changes in real time (e.g. a 
parameter is removed)? would the current subscription be rejected? or would 
the notify messages keep updating (in this case without the modified 
parameters)? Would the consumer be required to monitor the parameter 
definitions, then react to the change (e.g. deregister the subscription list 
containing the deleted parameter then register the list again minus the 
deleted parameter)? 


CATEGORY OF REQUESTED CHANGE: 

Technical Fact X Recommended Editorial 


SUPPORTING ANALYSIS: 



DISPOSITION: 



